home *** CD-ROM | disk | FTP | other *** search
/ Collection of Tools & Utilities / Collection of Tools and Utilities.iso / network / pdether.zip / PDETHER.DOC < prev    next >
Text File  |  1991-11-01  |  8KB  |  209 lines
  1.         Ethernet Packet Driver MLID, v1.01
  2.  
  3. Introduction
  4. ------------
  5.  
  6. PDEther.Exe is an ODI to Packet Driver adaptor.  It provides an ODI
  7. interface for an arbitrary Ethernet Packet Driver.  This allows ODI
  8. access to any Ethernet board which has a Packet Driver and also
  9. allows Packet Driver applications and ODI applications using
  10. different network layer protocols to coexist in the same DOS system.
  11.  
  12. Using PDEther
  13. -------------
  14.  
  15. In Packet Driver terms, PDEther is an application.  In ODI terms, it
  16. is a LAN driver, also know as a "link driver" or "MLID".  The loading
  17. sequence will be something like this:
  18.  
  19. 1. Load the packet driver supporting your card.
  20. 2. Load LSL.
  21. 3. Load PDEther.
  22. 4. Load IPXODI, NetX, and/or other ODI applications.
  23.  
  24. Like all good ODI modules, PDEther reads Net.Cfg for configuration
  25. information.  The next section of this document describes PDEther's
  26. requirements for Net.Cfg, including a description of PDEther's Link
  27. Driver section.
  28.  
  29. Net.Cfg
  30. -------
  31.  
  32. You must configure at least one 1514 byte ODI receive buffers in the
  33. Link Support section of the Net.Cfg file using the Buffers keyword:
  34.  
  35.     Link Support
  36.         Buffers 4 1514
  37.  
  38. A few extra buffers may allow PDEther to handle congested conditions
  39. better.  If no buffers are allocated or they are not 1514 bytes long,
  40. PDEther prints a warning message.
  41.  
  42. Some packet drivers will work with smaller buffer sizes, but it is
  43. difficult to tell which will and which won't.  For that reason, i
  44. recommend always using 1514 byte ODI buffers but, on the other hand,
  45. PDEther will try to muddle through even if 1514 byte buffers are not
  46. available.
  47.  
  48. Your Net.Cfg file should also contain a Link Driver section for
  49. PDEther.  Such a section begins with the unindented text "Link
  50. Driver PDEther".  As is normal in the Net.Cfg file, the section
  51. continues until the next unindented line.  (In other words, all lines
  52. in the Link Driver section should be indented by one or more spaces
  53. or tabs.)
  54.  
  55. PDEther ignores case, extra white space, and comments when reading
  56. Net.Cfg.  Comments begin with "#" and continue to the end of the
  57. current line.
  58.  
  59. The Link Driver section of the Net.Cfg file supports three keywords:
  60.  
  61. INT <hex interrupt>
  62.  
  63.     The INT line specifies the software interrupt of the Packet
  64.     Driver the MLID should use.  The value is a hex number
  65.     between 60 hex and 80 hex.  The number may optionally be
  66.     preceeded by "0x" to indicate a hex number, but the number is
  67.     read in hex whether or not the "0x" is present.  If PDEther
  68.     sees no INT line, it uses the Packet Driver at software
  69.     interrupt 60 hex.
  70.  
  71. FRAME Ethernet_II
  72.  
  73.     This is just the standard frame type parameter that all MLIDs
  74.     support.  Since this driver only supports Ethernet, only
  75.     "Ethernet_II" is accepted.  For the same reason, this line is
  76.     entirely optional.
  77.  
  78. PROTOCOL <protocol name> <hex E-type> Ethernet_II
  79.  
  80.     This is the standard protocol identification line.  The
  81.     protocol name (case insensitive) identifies the protocol
  82.     to LSL.  E-type is a hex number indicating the Ethernet type
  83.     value for this protocol.  (Again, it may be preceeded by "0x",
  84.     but it is always interpretted in hex.)  The media name is
  85.     Ethernet_II.  Again, Ethernet_II is the only media supported,
  86.     so contrary to standard Net.Cfg practice, specifying
  87.     Ethernet_II is optional.
  88.  
  89. ===>>>    *ALL* protocols this driver is to support must be specified
  90.     in the Link Driver section, since the MLID must be able to
  91.     tell the Packet Driver specifically about any protocols the
  92.     MLID wants to receive.  There is one typical Novell exception:
  93.     IPX is set up automatically if it is not specified explicitly.
  94.  
  95.     On the other hand, do *not* specify protocols which the
  96.     packet driver is supporting directly.  This will make PDEther
  97.     take control of those protocols, so your packet driver
  98.     application won't be able to use them.
  99.  
  100. Here are some example lines.  By the way, if you are using an ODI
  101. TCP/IP protocol stack, you will need these protocol lines in your
  102. Net.Cfg file to tell PDEther about the IP protocols.
  103.  
  104.     Int 60
  105.     Frame Ethernet_II
  106.     Protocol IP   800  Ethernet_II
  107.     Protocol ARP  806  Ethernet_II
  108.     Protocol RARP 8035 Ethernet_II
  109.  
  110.  
  111. Loading a Packet Driver
  112. -----------------------
  113.  
  114. PDEther supports the 1.09 Packet Driver specification.  I assume
  115. later Packet Driver interface versions will also work.  In addition, I
  116. have no particular reason to think it wouldn't work on older Packet
  117. Driver interfaces, since it uses no features flagged as new in 1.09,
  118. but i've only been using 1.09.
  119.  
  120. Releases of the Clarkson Packet Drivers since release 7 support
  121. version 1.09 of the spec.  Release 7 was also the first Packet
  122. Drivers which support the "raw" 802.3 IPX framing convention via "-n"
  123. switch described below.  At this time of this writing, the latest
  124. Clarkson release is release 9.
  125.  
  126. The details of loading a Packet Driver should be provided with your
  127. Packet Driver and are beyond the scope of this document.  Generally,
  128. you tell the packet driver which software interrupt to use and how to
  129. talk to the hardware through parameters on the command line.
  130.  
  131. Standard Packet Drivers take *all* input in decimal by default,
  132. although you may specify hex by using the "0x" prefix.  This is
  133. counter-intuitive, since almost all parameters to any packet driver
  134. are numbers which make little or no sense in decimal.
  135.  
  136. Standard Packet Drivers take the software interrupt as the first
  137. argument.  The software interrupt *must* agree with the INT parameter
  138. in the Link Driver PDEther section of the Net.Cfg file.  (But again,
  139. remember to prefix the packet driver parameter with "0x".  The INT
  140. parameter in Net.Cfg is always interpreted as a hex number.)
  141.  
  142. If your network uses the popular "Ethernet_802.3" frame type (the
  143. illegal Novell "raw" 802.3 framing type) for IPX traffic, give the
  144. Packet Driver the "-n" switch to get that framing for IPX traffic.
  145. This tells the Standard Packet Drivers to send IPX traffic in the
  146. "raw" 802.3 format.  The "-n" switch does not affect other
  147. protocols.  The default IPX protocol ID (8137 hex) *must* be used so
  148. the Packet Driver can identify IPX packets.
  149.  
  150. Note that when using the "-n" switch, you continue to specify
  151. "Ethernet_II" in the Net.Cfg file; you do *not* indicate the frame
  152. type Ethernet_802.3 as you would in a normal ODI Link Driver.  The
  153. "raw" 802.3 framing is handled by the Packet Driver without PDEther's
  154. knowledge.
  155.  
  156. Here's an example of a typical packet driver command line which loads
  157. a Packet Driver on software interrupt 60 hex to support an NE2000
  158. ethernet card on hardware interrupt 5, port 340 hex, using normal
  159. Ethernet framing.
  160.  
  161.     ne2000 0x60 5 0x340
  162.  
  163. To load the same Packet Driver but have it send IPX packets using
  164. Novell's default Ethernet_802.3 framing instead of the more proper
  165. Ethernet_II, use a command line like this:
  166.  
  167.     ne2000 -n 0x60 5 0x340
  168.  
  169. Limitations
  170. -----------
  171.  
  172. Although the Clarkson Packet Drivers now support 802.3/802.2 and
  173. 802.3/802.2/SNAP, this MLID does not support those two framing
  174. types.
  175.  
  176. Some of the less important features of the Packet Driver are not
  177. supported.  For example, it cannot deal with a Packet Driver
  178. supporting multiple boards.
  179.  
  180. If you are using PDEther under applications other than IPX, each
  181. protocol (except IPX) must be explicitly listed in the PDEther's Link
  182. Driver section.  Although "normal" from the point of view of the
  183. Net.Cfg design, it is quite abnormal in practice.  Novell's TCPIP for
  184. ODI, for example, will automatically add the TCP/IP protocol IDs if
  185. they are not present, but THIS DOES *NOT* HELP PDEther which must
  186. find them in its section of Net.Cfg.  This is unfortunate.  Failure
  187. to list the protocols in the Net.Cfg file is not a detectable error
  188. so all the software will be satisfied, but no arriving packets will
  189. be delivered to IP.
  190.  
  191. Bibliography
  192. ------------
  193.  
  194. FTP Software, "PC/TCP Packet Driver Specification", version 1.09,
  195. September, 1989.
  196.  
  197. Novell, "Open Data-Link Interface Developer's Guide for
  198. NetWare DOS Workstation Drivers", Revision A, 30 January 1991.
  199.  
  200. Conclusion
  201. ----------
  202.  
  203. Let me kno